This page help you to change cost/revenue element base
Use this page when you wan to consider additional options during upgrade to Application 8.
In Applications 8, it is now possible to use a different code part than Account as Base for deriving the Cost/Revenue Elements. For more information and the benefits of this functionality, see the IFS Applications 8 product news presentation for Project Based. This section is only relevant if for existing customers that wish to utilize the possibility of changing the code part used as Base for deriving Project Cost/Revenue Elements (for example from Account to another code part).
Preparation for the change: If an existing customer wishes to change the Base, some special consideration is needed as existing postings may not have a value for the new code part set as Base, which means it is not possible to derive a Cost/Revenue Element using the standard functionality. To help avoid this situation, it is recommended to plan the change of the cost/revenue base by bringing the new code part into use, well in advance before the actual change should occur. In this way, values for the code part will be included on the postings.
For some historical data, values may still be missing for this code part. To handle these transactions, data has to be set up in the Secondary Project Cost/Revenue Element window, where Accounts are mapped to Cost/Revenue Elements. The data in this secondary table will only be used to derive Cost/Revenue Elements for existing General Ledger Voucher Rows that lack a value for the new code part used as Base.
Cost/Revenue Elements for other types of project connections will generally be
derived using a ‘simulated posting’ according to the current Posting Control
set-up, an exception being manually entered Cost/Revenue Elements. This means
there may be discrepancies in the Cost/Revenue Elements used for
Planned/Committed Cost compared to Actual Cost for historical data if you decide
to change the Base. These discrepancies are normal for an upgraded project and
only represent historical records.
When upgrading from a previous version of IFS Applications, it is recommended to first follow the entire standard upgrade process (see next section Upgrade Considerations) and verify that all Cost/Revenue Elements are correctly updated. Then at a later time the following process for changing the Base can be done.
However if it is required to change the Cost/Revenue Element Base as part of an
upgrade, you may wait to run the last script
(POST_Proj_App8_ManualCostRevenueRefresh.sql) until you have finished all the
steps for changing cost/revenue element base. In this way, the Project
Connections are only refreshed once, but doing so means that it may be more
difficult to work out the cause of any errors.
The process for changing the Base is as follows. Note that this process can be performed for one company at a time as the Base is company specific. Because the process involves deleting existing data, it is recommended that a backup is made of the database prior to performing this process.
Step 1 – Update all objects
Before changing the Cost/Revenue Element Base, all existing execution objects reporting cost or revenue to an activity have to be fully processed and any resulting vouchers updated to the General Ledger. Execution objects are objects with financial data and which are project-connected. The business processes include (but are not limited to) finalizing all existing reporting on all projects, updating all transactions and creating vouchers, and updating all vouchers to the GL etc.
Step 2 – Copy Cost/Revenue Element mappings
Open the Project Cost/Revenue Element per Code Part Value window, and then use the RMB option for ‘Secondary Project Cost/Revenue Element’. In the window that opens, use the RMB function ‘Copy Cost/Revenue Elements to Secondary Mapping’. This will copy the existing mappings to this new window, which will be used when a Cost/Revenue Element cannot be derived for an existing GL Voucher Row due to missing a value for the new Base. Alternatively, mappings can be set up manually. After the copy has been performed, populate the window to verify that the data has been copied correctly.
When upgrading from an older version of IFS that did not use Project Cost
Elements it is necessary to determine if there are any project transactions
where a value for the code part that is going to be used as the base are
missing. Once this is determined, the accounts that were used for these
transactions must be manually added to the ‘Secondary Project Cost/Revenue
Element’ table. A query that could be used to ascertain these accounts is:
SELECT DISTINCT company, account,
IFSAPP.Account_API.Get_Description(company,account)
FROM IFSAPP.gen_led_proj_voucher_row t
WHERE code_XX IS NULL
AND project_activity_id IS NOT NULL
ORDER BY company, account
Here we assume that IFSAPP is the application owner in the database, if not
adjust the statement accordingly. Also enter the correct value of the code part
that will be used as the new ‘Base’ in place of code_XX, for example Code_C or
Code_D. This statement can be executed as an External Data query in Microsoft
Excel, or be run in Oracle SQL*Plus or any other SQL tool.
Step 3 – Delete existing Cost/Revenue Element mappings
Go back to the Project Cost/Revenue Element per Code Part Value window and delete all existing mappings.
Step 4 – Change the Base and update Posting Control
Open the Define Code String window, highlight the Code Part you wish to use
as Base for Cost/Revenue Elements and use the RMB option for ‘Set as Base for
Project Cost/Revenue Element’.
As part of changing the Base you also have to update Posting Control so that any
postings which include the Project code part also include a value for the new
code part set as Base.
Step 5 – Define Cost/Revenue Element mappings
Open the Project Cost/Revenue Element per Code Part Value window from the Navigator (i.e. rather than from the Recent Screens option), and it will now show the new code part set as Base as the first column. Link the values for this code part to Cost/Revenue Elements as required.
Step 6 – Run the Project Connections Refresh function
Run the Project Connections Refresh function, either by running the
POST_Proj_App8_ManualCostRevenueRefresh.sql script or the corresponding
function in the application.
More details about this running this script are available in the IFS
Applications 8 Technical Documentation – in the IFS Installation Guide
Upgrading Preparing for Upgrading Installation Roadmap section. Refer to the
Product Specific Information for the component PROJ 2.0.0.
Step 7 – Verify data
Verify that all Project Connections have Cost/Revenue Elements as expected. Also verify that no errors have been given in the ‘Project Connections Refresh Details’ window.
Note that a ‘simulated posting’ is used to derive values for
Planned/Committed Cost etc. for the Project Connections (which will consider
Posting Control for the new code part used as Base), whereas the secondary
mapping will be used for Actual Cost when there is no data for the new code part
used as Base on the GL Voucher Row. This means there can be a mismatch between
the Cost/Revenue Element used for Planned/Committed Cost compared to Actual Cost
for historical objects after changing the Base.